





SSHARE= 








Sh 


SHARE SESSION REPORT 


61 M503 VM Capacity Allocation Program 125 
SHARE NO. SESSION NO. SESSION TITLE ATTENDANCE 
CME (Computer Management & Evaluation) Sal Asad RCH 
PROJECT SESSION CHAIRMAN ——~—S'SINST. CODE 


RCA/CISS Bldg 204-2 Route 38, Cherry Hill, N.J. 08054 (609) 338-6543 
SESSION CHAIRMAN'S COMPANY, ADDRESS, AND PHONE NUMBER 


VM Capacity Allocation Program 
George S. Peters 
IBM 
Information Products Division 
Boulder, Colorado 
Installation Code: IBB 
Computer Niseawettan ha Evaluation Project 


Session M503 


ABSTRACT 


In any computer environment poor response time, system thrashing, and 
inequitable distribution of computer resources arise when the prime-shift 
workload exceeds system capacity. This paper describes CAP (Capacity Allocation 
Program)--a facility that apportions system resources in a Virtual Machine (VM) 
environment. User groups are granted an allocation based on their usage 
forecast. Those groups that use less than their allocation are rewarded with 
good service; those groups that use more than their allocation may receive 
degraded service. 
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OVERVIEW 


When the prime-shift load of a computing system exceeds the system capaci- 
ty, three consequences normally surface: a) the system begins to thrash 
and system throughput and DP investment are substantially reduced, b) 
response time is poor and user productivity drops dramatically, and c) 
user groups complain that the resource is not being distributed 
commensurate with the needs of the business (i.e., groups with critical 
schedules are not receiving the best service). This paper describes the 
Capacity Allocation Program (CAP) that represents a solution to these real 
problems. 


CAP consists of a series of programs that permit an installation to repre- 
sent the existing VM capacity as a 360-degree pie. The pie is divided 
among the various user groups based on their forecasts. Service is doled 
out depending on whether a group is using more or less than its 
allocation. Groups using less than their allocation receive good service; 
groups using more than their allocation receive degraded service. 


Because CAP is active only during prime shift, those users over their 
allocation, as well as those groups desiring to stay under theirs, are 
motivated to move work offshift, thus reducing prime-shift demand and 
increasing offshift usage. Finally, groups identified by management as 
working on the most important projects can be given a large enough allo- 
cation to continue their work efficiently--even during periods when 
demand exceeds capacity. 
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System Thrashing 


Software systems run efficiently when there is a sufficient supply of each 
of the required resources. When there is contention for a resource, a 
bottleneck develops, queues build, and the service time for each trans- 
action increases. For example, when the demand for real storage is great- 
er than the supply, transactions wait longer in the ready queue for 
storage to become available. When the system detects this shortage, it 
begins to "steal" pages from other non-active transactions which, when 
activated, add further to the overhead. When the system incurs this com- 
pounding overhead, the system is said to be thrashing, that is, the system 
loses its ability to do productive work because it begins serving itself 
rather than its users. To the extent that DP management permits this to 
happen will determine the extent to which the equipment investment is 
lost. CAP helps reduce system thrashing. 


User Productivity Loss 


Previous studies show that user productivity varies greatly with system 
load. Therefore, it becomes extremely important that DP management either 
ensure adequate capacity or control the workload so that the system per- 
formance remains good at all times. Otherwise, user productivity suffers, 
product schedules slip, and the associated cost increases. 


When user response deteriorates from one to three seconds, a significant 
portion of a user's time is wasted in idleness. At $30 per hour and 200 
users logged on, lost user productivity is substantial. Because CAP helps 
stabilize the system, user response time is more consistent, thus user 
productivity is enhanced. 


Allocation Problem 


VM requirements of user groups depend on a number of variables. 

Schedules, workload characteristics, and previous-day availability are 
just a few. When too much work arrives at the same time--regardless of 
the reason--the system begins to thrash; users get frustrated; and sched- 
ules slip. Some project managers feel thwarted and demand an explanation. 
When this occurs, the existing resources need to be allocated to the most 
worthy projects--at the expense of the remaining groups. CAP fulfills 
this need by apportioning existing capacity consistent with the needs of 
the business. 


CAP permits the VM system processor to be viewed as a collection of small- 
er processors of varying capacity. Initially, a user group is given a 
small processor (small slice) but as requirements of the project increase, 
the user group is given a larger processor. A group working on a less 
important project is given the smaller processor. The resource granted to 
a particular group can be varied as the needs of the business change. 


User Involvement 
Good school administrators and teachers want parents to become involved in 


the school system because they know that involved parents are generally 
more satisfied with the system. Users of DP equipment are no different. 


When they become involved in the problems of resource distribution and 
understand the needs of the total community, users are much less likely to 
complain about the service they receive. CAP encourages user involvement 
by forcing users to meet together, to understand the business needs and to 
distribute the computing resources equitably. 


Prime Shift Demand 


As more of the work force goes online, more people depend on the system 
during prime shift. As DP management acquires more hardware to meet prime 
shift demands, more of the offshift's wasted. Figure 1 graphically illus- 
trates the offshift capacity that goes unused in many VM installations. 
This trend renders prime-shift time more expensive and offshift less 
expensive. To the extent that users can be motivated to use the offshift 
cycles (preferably by moving the work, not the people, offshift) less 
offshift is wasted and prime-shift demand is lessened. CAP provides the 
motivation necessary for people to change their working habits--to reduce 
their prime shift requirements and to increase their offshift usage. For 
example, a technical writer who is formatting a 120-page document on prime 
shift might want to break it into smaller pieces and format only the 
smaller sections during prime shift and schedule the formatting of the 
complete document to run during the offshift. 
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Figure 1. CPU Utilization Versus Time of Day 


Forecasting Accuracy 


Workload forecasting is an important part of capacity planning. Forecas-~ 
ters who take their job seriously and do a good job of prediction do a bet- 
ter job capacity-planning. Because groups that forecast poorly are ; 
visible, CAP can be used to degrade the service of those groups, resulting 
in a higher motivation to forecast well. 
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CPU Usage Sensitivity 


In many installations users take the system resource for granted. Even 
when the application requires one-third of the CPU, the user feels as 
though the required resource should be available. Users sometimes forget 
that with 200 other users logged on, one-third of the CPU just isn't going 
to be available. 


The real problem, of course, is that most users are not sensitive to the 
CPU resource. Users often do not know how much resource their application 
requires. With CAP, group users are reminded how much resource they are 
using. When a user on a given day uses 1/3 of the CPU and causes others in 
the group to exceed their allocation, peer pressure motivates the user to 
look carefully at the application to determine if it can be (a) run on the 
offshift using the batch facility (b) modified to take fewer resources (c) 
run less frequently or (d) replaced with a more efficient process. 


CAP DESCRIPTION AND PROCEDURE 


CAP helps solve these problems by helping to control system workload. 
Control is effected in four ways: a) users in the groups that have used 
more than their fair share will have their priority lowered. This reduces 
the overall workload by giving the resource to the users who are under 
allocation at the expense of those over their allocation; b) when a group 
gets close to or exceeds its allocation, the managers or coordinators of 
the group can meet and discuss ways of moving work (not people) offshift 
by carefully distinguishing real, prime-shift work from offshift work 
traditionally run on prime shift; c).when the need arises, groups can help 
reduce prime-shift load by staggering work hours. Some members arrive ear- 
ly and leave early; others arrive late and stay late; and finally, d) the 
ultimate but undesirable workload reducer is to force off the system the 
users in those groups that have used more than their fair share. 


CAP User Group 


A user group consists of a set of departments defined to the system. To 
define a group, a group number is specified, followed by a list of depart- 
ments that compare the group. Figure 2 illustrates the Group Definition 
File. Group 103 has an allocation of three CPU minutes per day, and con- 
sists of users in departments 61G, 61H, and 619. 


S&F 


GRP 
100 
102 
103 
105 
106 
108 
109 
110 
111 
112 
113 
114 
115 
116 
119 
120 
123 
124 
126 
127 
128 
129 
130 
199 
200 
201 
250 
300 
301 
350 
400 


— 450 


500 
550 
600 
650 
990 
999 
TOT 


DES ALO 


JAC 
RJJ 
DB 

JHH 
MEG 
JWW 
JWS 
AH 

ABH 
RZW 
WIB 
DTF 
FC 

DEB 
RAH 
WBP 
DA 

TMH 
DRM 


CAQ 


RFK 


003 
007 
003 
002 
000 
006 
003 
005 
001 
105 
003 
000 
000 
017 
007 
004 
004 
065 
066 
000 
001 
004 
000 
000 
005 
004 
007 
012 
012 
061 
010 
002 
007 
020 
004 
002 
002 
000 
000 


Figure 2. 


Capacity Pie 


The capacity pie is the number of CPU minutes available in a prime shift 


DEPT 

61C ,69A,69B,69J, 69K, 69L, 69N, 69Q, 69R, 695 692,691,690 ,69V 
690, 693,694,699 

61G,61H,619 

61F ,664,67V,67Y,674,61E,61F ,61J,61K,61L,61M 
61B,61R,61W,61Y,614, 66L, 66N, 66P , 66R, 66V , 66W, 68F ,68Q,68R 
60D, 60N, 60S ,60U,61G,61K,63A, 65D, 65E , 666 , 68C, 68P, 68U, 68W 
61D ,65U,66A,66B, 66D, 66E, 666, 68V 

61E,631 

61P,64A4,64C,64K,61J 

619,635, 638,639,659 

63H, 633,634, 66H, 63F 

643 ,63C ,63D, 632,636 ,68B,61V,611,61Q, 63E 

641,615,618 

60H, 60K, 60T,60Z,611,64M,69C, 69D, 69H, 612, 60E,60J,69E,61M 
617,689,681 

60M,60R ,60Y,61V,68S ,635,63K,63L,63Q,63R,655 656,657,658 
677,63N,651,653,688 ,645 

65Y,61N 

61A,64Y,647,65F 

683,684,685 ,686,61A,61T,61R 

64P 

60B , 64H, 64V, 65T, 65W , 650, 66K,67M,67Z,60C ,63B ,63M,63Y,64R 
60Q,69P 

61T ,61U, 663,646,618, 64B, 616 ,60W,60G, 60V,63W,63T, 610,646 
905,781,907, 144,175,176,161,147,19B, 19K, 111,744,756, 785 
710,717,711, 71A,71B,71D, 71H, 751,700, 706,741,745 145,790 
400 ,401,403,407 ,413,443,445 ,446 416,406 ,454 453,450,448 
919,911,936, 937,938,951, 953,954,955, 950,956,931 

958,959 ,951,957 

931,934,935, 939,941,943, 944,945,947 948,940,941 
816,811,831, 831,843,847 ,841, 863,865 913,800,893 ,891,813 
965,966,967, 968,969,961, 976,978,979, 984,986 , 987,999,910 
503,504,505,507,509,513,514,518,511,515,519,914 

78A,78C ,78D, 78E, 78F , 78K, 78L, 78M, 78N, 78P, 78R, 787, 78V, 79B 
110 

991,100,101, 103,104,105,106, 107,108,109, 101,168 
946,949, 71C,196,045, 785,535,516 

XXX 


Group Definition File 


day. For example, if one expects 95-percent CPU availability at 


90-percent busy for a 9.5-hour, prime s 
.95 X .90 X 9.5 X 60 or 487 CPU minutes. 


for prime shift, only prime shift is included. ) 


hift, then the capacity pie equals 
(Because the greatest demand is 


Pie: Slice Allocation 


With each user group present at an allocation meeting, the total prime 
shift capacity is divided. The allocation algorithm is a function of the 
group's forecast and the previous month's usage. For example, 


Slice = 487 X (F(i)/F(t)) X R(i) 


where F(i) is the group's forecast 
F(t) is the total of all forecasts 
R(i) is an adjustment factor based on the group's 
previous month's usage, allocation, and forecast 


When all slices have been determined, they are entered into the third col- 


umn of the Group Definition File (Figure 2), and must add to a value equal 
to the size of the pie. 


Usage Tracking 


During third shift when an excess of system capacity is available, CAP 
calculates usage for the previous day. Accounting records are scanned and 
CPU usage and terminal-connect time are accumulated by department and by 
group. The value is recorded in the Group Usage File in the column PREV 
DAY PRIME USAGE (CPU minutes), shown in Figure 3. At this time the 10-day 
running average is also calculated (and placed in the third column). 


NEW-10-DAY-USAGE = (OLD-10-DAY X 9 + PREVIOUS-DAY) / 10 


The last column of Figure 3 shows the 10-day average connect time in 
hours. Using the ratio of usage/connect, one can calculate a CPU-group- 
intensive value where the larger the value, the more CPU intensive the 
group is. For example, in group 100 the usage is two CPU minutes, and the 
connect time is 14.1 hours giving a ratio of 2/14 = .14. This means that 
group 100 uses .14 CPU minutes for each hour of terminal-connect time. 
Contrast this value with .84 for group 116 (22.8/27.3), a more 
CPU-intensive group. Also interesting is to compare the individual group 
values with the TOT value of 452/1826 = .24, which is the intensive value 
for all system users combined. This CPU-intensive-group value can be 


helpful in forecasting because it provides usage profile information 
about the group. 


Lg % 


PRVDAY AVERAGE GROUP GROUP PRVDAY AVERAGE 


THE 
GROUP PRIME 
NMBR USAGE 
100 0003. 
102 0006. 
103 0002. 
105 0001. 
106 oooo. 
108 oooo. 
109 0003. 
110 0007. 
111 0015. 
112 0134. 
113 0002. 
114 0000. 
115 oooo. 
116 0076. 
119 0010. 
120 0002. 
123 0001. 
124 0032. 
126 0031. 
127 0000. 
128 oooo. 
129 oooo. 
130 oooo. 
199 oooo. 
200 0002. 
201 0005. 
250 0010. 
300 0019. 
301 0013. 
350 0056. 
400 0012. 
450 0003. 
500 0006. 
550 0014. 
- 600 0004. 
650 0003. 
990 0000. 
999 0000. 
TOT 0488. 
Figure 3. 
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a 
7 
8 
0 
8 
5 
3 
3 
6 
5 
4 
0 
8 
9 
3 
3 
5 
4 
0 
4 
3 
0 
2 
3 
6 
5 
1 
2 
7 
6 
1 
5 
4 
8 
6 
9 
8 
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PRIME 
USAGE 
0002. 
0007. 
0004. 
0002. 
0000. 
0004. 
0002. 
0004. 
0020. 
0099. 
0003. 
0000. 
0000. 
0022. 
0010. 
0001. 
0002. 
0055. 
0039. 
0000. 
0000. 
0001. 
oooo. 
0000. 
0005. 
0006. 
0007. 
0016. 
0012. 
0063. 
0011. 
0003. 
0007. 
0025. 
0002. 
0004. 
0001. 
0000. 
0452. 
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ALLO- BASE 
CATION PRIOR 
0003 64 
0007 66 
0003 80 
0002 66 
0000 64 
0006 64 
0003 64 
0005 64 
0021 64 
0105 64 
0003 65 
0000 64 
0000 64 
0017 75 
0007 78 
0004 64 
0004 64 
0065 64 
0056 64 
0000 364 
0001 64 
0004 64 
0000 64 
0000 64 
0005 66 
0004 85 
0007 67 
0012 76 
0012 66 
0061 66 
0010 70 
0002 82 
0007 66 
0020 72 
0004 64 
0002 94 
0002 64 
0000 =00 
0464 00 


PRIME 
CONNE 
0013. 
0025. 
0014. 
0010. 
0000. 
0013. 
0017. 
0026. 
0056. 
0203. 
0010. 
0002. 
0000. 
0029. 
0031. 
0016. 
0002. 
0110. 
0085. 
0000. 
0003. 
0005. 
0000. 
0003. 
0015. 
0058. 
0054. 
0192. 
0150. 
0243. 
0126. 
0029. 
0056. 
0110. 
0032. 
0028. 
0012. 
0009. 
1803. 


Group Prime Shift Usage and 


PRIME 
CT CONNE 
0014. 
0043. 
0019. 
0013. 
0000. 
0012. 
0015. 
0016. 
0053. 
0183. 
0017. 
0001. 
0000. 
0027. 
0030. 
0011. 
0008. 
0139. 
0115. 
0000. 
0002. 
0007. 
0000. 
0000. 
0024. 
0074. 
0041. 
0160. 
0121. 
0235. 
0137. 
0027. 
0049. 
0125. 
0032. 
0030. 
0024. 
0003. 
1826. 
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Time File 


‘Current Priority 


Current Priority (CP) is the priority that a user is currently running 
with when logged on and active. The value can range from a high priority 
of 0 to the lowest priority of 98--just reversed from what we would think. 
As the user's CP increases, he gets less service than other users competing 
for CPU time. An increase of 10 in priority results in decreasing a 
user's service (relative to other users) by one-half. The effect of a 
given change in priority may vary widely, depending on the nature of work 
being done by the user and by other users on the system. Priority change 
primarily affects non-trivial transactions, (meaning, generally, work 
done in excess of 0.1 second of CPU time after the most recent terminal 
input or output). Priority change should not significantly affect trivial 
transactions (i.e., the first 0.1 second of CPU time after terminal input 
or output). 


Normal Priority 


The CP can take on the value of the Normal Priority (NP), that value given 
to the majority of users requiring normal service. 


Base Priority 


The CP can also take on the value of the Base Priority (BP), a priority 
calculated by CAP during the offshift. That is, during third shift, the 
10-day running average (usage) is compared to the group allocation. If 
the usage is less than the allocation, the group is considered to be an 
under-allocation group and is given normal priority. If the group's usage 
is greater than the allocation, the group is an over-allocation group and 
a Base Priority is calculated, which depends on the percent that the group 
exceeds its allocation. In Figure 3, group 103 has an allocation of 3 
minutes per day. The group's average usage is 4.6, or 1.6 minutes above 
their allocation, resulting in a BP of 80 for the next working day. The 
algorithm used to calculate BP is 


BP = NP + ((((USAGE * 10) / ALLOC) - 10) * 3) 


The CP will be set equal to the BP only during prime shift and only when 
system performance warrants. (This is discussed later under Prime Shift 
Execution. ) 


Hit List 


Again during third shift, and after Base Priorities have been calculated 
for each group, CAP flags each group that has a Base Priority that exceeds 
the Normal Priority. From this set, CAP develops a HIT LIST of USERIDS 
and corresponding Base Priorities. The HIT LIST consists of all those 
users in groups who are over their allocation. These USERIDS will have 
their priorities adjusted on prime shift when performance warrants. Fig- 
ure 4 shows an example of the HIT LIST. 
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AIELLO 66 
AJONES 98 
ANELSON 67 
BJFOSTER 66 
CHAMBERS 93 
CLEMENTS 66 
DALSETH 66 
DAVENPA 66 
DRAPER 93 


DROBERTS 67 


WISER 93 


WPBROWN 98 
WPETERSN 66 
YODER 66 
YOUNGWV 93 
ZIEMKOWS 66 
ZIMMER 98 


Figure 4. Hit List File 


Load Indicator (Expansion Factor) 


The Expansion Factor (EF) is a dimensionless number--a measure of system 
load. In a non-technical sense, it is the time the keyboard is locked, 
divided by the CPU time it takes to process the transaction. In this 
paper, it is the output from the INDICATE LOAD command. A high expansion 
factor means that the system is thrashing and user response time has 
increased dramatically. 


Prime Shift Execution 


Throughout prime shift, CAP interrogates the system load via the Expansion 
Factor, and if necessary, sets the priorities of those on the HIT LIST, 
sleeps for an interval of 10 to 15 minutes; sets priorities again; sleeps 
again; etc. Such priorities set by CAP are always greater than or equal 
to NP. 


When CAP awakens from a sleep interval, the current EF is compared with _ 
five system values El, E2, X, Y,and Z, that represent five levels of sys- 
tem degradation--El being slightly degraded; Z being very degraded. 


When the EF reaches El, the Base Priorities are invoked for all users on 
the HIT LIST. This action frees up some resources for the 
under-allocation users at the expense of the over-allocation users. As 
the BPs are invoked, the user is notified one time: 
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YOUR PRIORITY HAS BEEN CHANGED BECAUSE YOUR GROUPS USAGE 
EXCEEDS ITS FAIR SHARE. YOUR PRIORITY = CP AND WILL VARY 
WITH SYSTEM LOAD. PLEASE DO NOT EXECUTE ANY LONG RUNNING 
JOBS BECAUSE THEY MAY NOT COMPLETE OR BECAUSE YOU MAY BE 
FORCIBLY LOGGED OFF DUE TO A CRITICAL SYSTEM LOAD. 

FOR MORE INFO, TYPE CAPNEWS. 


As the EF varies between El and E2, the current priority of users on the 
list will take on values between the Base Priority and the maximum (98) as 
illustrated in Figure 5. The objective is to have sufficient people on 
the HIT LIST so that the EF will float between E1 and E2. 


98 |---> RAKE REREE 
| * 
| * 
P | : 
R | * 
I | * 
0 | * 
R "BP! |---> % 
I | * 
53 | * 
Y "NP! | teededededrdee 
| 
| ‘ 
| 
| 
| 
| 
| : ‘ : ; ‘ 
i eee | ere cee es (Se Ie eetecewene Coane, 
0 El E2 xX Y 2 


System Expansion Factor 


Figure 5. VM Current Priority Versus System Load 


When the EF reaches X, the system is considered minimally degraded and 
more action must be taken. Users on the HIT LIST are sent a plea 
message--an attempt to bring the system back in line by having all 
over-allocation users defer their work by voluntarily logging off. 


When the EF reaches Y, the system is considered degraded and more action 
must be taken. At this point all users on the system are sent a plea--an 
attempt to prevent forced logoff of those on the HIT LIST. This technique 
is effective if not exercised too often. Frequency can be controlled by 


_ adjusting the value of Y. 
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GRP 


When the EF reaches Z, the system is thrashing; drastic action must be 
taken. Those on the HIT LIST are warned they have ten minutes to log off 
or they will be forced off the system. This action will free up enough 
resources to bring the system back in line. The intent is to favor those 
who have managed to their allocation at the expense of those who have not. 


Exception List 


If some user's work is more important than others in the group, the USERID 
can be placed in an EXCEPT list. When this is done, the user's usage still 
accumulates toward the total group usage but the user is exempted from the 
HIT LIST, and his other priority will be set to the Normal Priority. 


Offshift 


Figure 6 shows usage and connect-time data for offshift hours. The prima- 
ry use of this data is to track the change in offshift usage and offshift 
connect-time when user groups change their usage habits as a result of 
being constrained by limited capacity. Those groups that move work to the 
offshift can be favored with a somewhat larger allocation during prime 
shift. In this way people are motivated to carefully analyze their 
prime-shift:- work, ensuring that it needs to be run during prime shift. 


je 


THE PRVDAY AVERAGE GROUP GROUP PRVDAY AVERAGE 
GROUP OFFSHT OFFSHFT ALLO- BASE OFFSHFT OFFSHFT 
NMBR USAGE USAGE CATION PRIOR CONNECT CONNECT 


100 0000.8 0000.2 0003 00 0001.9 0001.1 
102 0000.0 0000.5 0007 00 0000.7 0003.2 
103 0000.0 0000.0 0003 00 0000.0 0000.0 
105 0000.0 0000.0 0002 00 0000.2 0000.2 
108 0000.0 0001.5 0006 00 0000.0 0000.8 
109 0000.2 0000.0 0003 00 0000.7 0000.2 
110 0000.5 0000.8 0005 00 0000.7 0000.6 
111 0001.8 0007.4 0021 00 0005.9 0006.0 
112 0312.0 0155.4 0105 £00 0036.5 0069.8 
113 0001.0 0000.1 0003 00 0001.9 0000.9 
116 0001.1 0018.6 0017 00 0004.7 0002.5 
119 0001.7 0000.1 0007 00 0005.6 0001.1 
120 0000.0 0000.0 0004 00 0000.0 0002.2 
123 0000.0 0000.0 0004 00 0000.0 0000.0 
124 0019.6 0062.1 0065 00 0026.5 0047.1 
126 0016.6 0016.0 0056 00 0016.5 0015.4 
129 0000.0 0000.1 0004 00 0000.3 0000.9 
130 0000.0 0000.0 0000 00 0000.0 0000.0 
199 0000.0 0000.0 0000 00 0000.0 0000.0 
200 0000.3 0001.2 0005 00 0001.2 0003.4 
201 0000.4 0000.5 0004 00 0002.6 0008.9 
250 0000.4 0000.4 0007 00 0003.1 0002.7 
300 0001.6 0001.3 0012 00 0010.0 0010.9 
301 0001.4 0001.3 0012 00 0012.1 0021.4 
350 0021.0 0059.3 0061 00 0080.9 0166.6 
400 0001.0 0001.8 0010 00 0044.1 0086.4 
450 0000.2 0000.0 0002 00 0001.3 0001.0 
500 0002.6 0007.1 0007 00 0023.8 0018.7 
550 0002.3 0006.1 0020 00 0023.0 0038.8 
600 0001.9 0002.1 0004 00 0013.3 0011.5 
650 0000.2 0000.2 0002 00 0000.6 0002.4 
990 0000.0 0003.3 0002 00 0000.2 0038.9 
999 0000.0 0000.0 0000 00 0000.1 0000.0 
TOT 0388.6 0347.4 0464 00 0318.4 0563.6 


Figure 6. Group OffShift Usage and Connect Time 


CAP and Adequate Capacity 


CAP is activated even during periods of adequate capacity because a) 
unique events may cause the capacity and workload lines to meet and prob- 
lems arise. For example, a heavy load on a day when the paging subsystem 

is only partially operational, b) CAP has benefits such as user involve- 
ment and user sensitivity that are ongoing regardless of the state of the 
system, and c) CAP will not adjust priorities until the expansion factor | 
reaches El, so users on the HIT LIST are not affected so long as the supply 
is greater than the demand. 
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CONCLUSION 


CAP works because it reduces prime-shift workload. It motivates users to 
carefully analyze their work and make sure that only prime-shift work is 
performed on prime shift. Figure 7 illustrates a typical group's 
usage-allocation plotted against time. Basically there are two pressure 
points, Pl and P2. At Pl, users are motivated to review their habits (and 
habits of their peers), because they fear the consequences of exceeding 
their allocation. Users will invariably identify jobs that need not be 
run on prime shift. For example, a user may decide that because he does 
not have time to analyze the results of a simulation run until the next 
day, he can submit the job to be executed at 2 a.m. and have the output 
available at 8 a.m. This frees up capacity. Multiplied by 100 users, the 
regained resource becomes significant. 


i 

' 

t 

t 

' 

fr 

t 

i 

1 

t 

+ 
le 

sf 


won eke eee ee he ee eee ALLOCATION 


OMA a AH Ss 


TIME (Weeks) 


Figure 7. Group Usage and Allocation Versus Time 


Note that the next pressure point is at P2. Here, all the users--large 
and small--are getting the terminal message (discussed previously) that 
they have used more than their fair share. Because it is in poor taste to 
use more than a fair share, discussions in the halls and around coffee 
machines transpire. This communication fosters sensitivity to the CPU 
resources. Sensitivity results in ideas and actions to reduce usage below 
the allocation. The fact that groups work to stay under (or to get under) 
their allocation changes user habits and reduces workload, which in turn, 
results in a smoother running system. 
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SUMMARY 
eee 
Before CAP, users felt that the CPU should always be available, regardless 
of the workload and current situation. After CAP, users began seeing the 


computer resource in the same way as managers see headcount. It is a lim- 
ited resource and must be planned carefully. Estimating either too little 


‘or too much can have severe consequences. 


15 


To? 


ACKNOWLEDGMENT 


etry rrereumeenernenrnnucaaennananenertnneteermnneataett ne tEt CLE e N A CTA LSC LC LLL CC LC OC 


The author thanks David Chess and other Yorktown professionals for provid- 
ing many CAP concepts taken from the VM Prioritizer. 
implementation efforts of Dave Anderson, Bob Greenwalt, and Don Wagler are 


appreciated. 


16 
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